• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    MONEY TRANSFER SYSTEM DOOR SERVICE.One process includes receiving a transaction request from a payment service provider on a computer. An end user identifier, including in the order, is mapped to an account number in the payment card system. The end user identifier identifies an end user who has received the payment card system account, and who is a subscriber to a closed loop payment system, operated by the payment service provider. Payment service provider funds are credited in an imaginary open loop system, identified by the account number of the payment card system. An authorization request for an open loop transmission is sent to the acquirer's financial institution, which represents a dealer that the end user is dealing with, and is received back from a payment card authorization system, by the same computer that received the transaction request from the payment service provider and generated the authorization request.
    公开号:BR112013001042A2
    申请号:R112013001042-8
    申请日:2011-06-30
    公开日:2020-08-25
    发明作者:Patrick Killian；Sandeep Malhotra
    申请人:Mastercard International Incorporated；
    IPC主号:
    专利说明:

    - Invention Patent Descriptive Report for "MONEY TRANSFER SYSTEM DOOR SERVICE." = RECIPROCAL REMISSION ON RELATED PATENT APPLICATION 7 This patent application claims the benefit of the provisional patent application US 61 / 364,934, filed on July 16, 2010, whose patent application is incorporated in this specification by reference . | BACKGROUND 7 The present invention relates to payment systems.
    In particular, some embodiments relate to processes, devices, systems, media and software products for interconnecting A closed loop payment systems with an open loop payment system. . Payment card systems are well-used.
    A prominent payment card system is operated by the assignee of the present invention, MasterCard International Incorporated, and its associated financial institutions.
    MasterCard's payment card system and similar systems are sometimes referred to as "open loop" systems, because transfers through the system can occur between two financial institutions (serving respective customers), which do not have contractual relationship with each other, but they are, differently, members of the system.
    In this way, transactions can move within the system of an account in one FL (financial institution), through the system, to an account in another FI, and not directly from one institution to the other.
    Consequently, a transaction between two end users does not require that both users are customers of the same payment service provider, and the system is "open" to any customer of any FI, who is a member of the system.
    A typical purchase transaction on an open payment system —deloop will be described below.
    To start the transaction, a customer visits a retail store operated by a dealer, selects items he wants to buy, takes the items to the point of sale
    + from the dealer, and presents your payment card at the terminal point. of sales. The point of sale terminal reads the payment card account number from the payment card customer, and then sends an authorization request to an acquiring financial institution (FI), with which the business has a relationship. The authorization request includes the payment card account number and the transaction amount, among other information. The authorization request is handled by the payment card system (which can be, for example, the well-known Banknet system, operated by the assignee of the present invention), from the acquiring FI to the issuing FI, which has issued the customer's payment card. . Considering that everything is in order, the issuing FI transmits 1 a favorable authorization response to the point of sale of the 4 dealer through the payment card system and through the acquiring FI. you. The transaction at the point of sale is then completed and the customer leaves the store with the items. A subsequent release transaction, initiated by the dealer, results in a transfer of the transaction amount from the customer's payment card account to an account, which belongs to the dealer and is held in the acquiring FI. The customer's payment card account can be, for example, a debit card account or a credit card account. In the first case, the release transaction results in funds being debited directly from the account. In the latter, the release transaction results in a debit being sent to the account, and the debit subsequently appears on the customer's monthly credit card statement.
    The above description of the typical transaction can be considered to be somewhat simplified in some ways. For example, a so-called dealer processing system (not shown) can be interposed between the POS terminal and the acquiring FI. As is familiar to those skilled in the art, a dealer processing system can be operated by or on behalf of the dealer, to form part of the communications route between the acquiring FL and the considerable number of POS terminals operated by the dealer. It is also often that a service
    O A O A Mi A O O Mo A O A A MA 3/29 - third party transaction processing can operate to control transactions. payment card transactions on behalf of the acquirer and on behalf of O a large number of other financial institutions. "While so-called open loop payment systems are a predominant mode of transaction control in the United States and other highly developed countries, closed loop systems can also be significant in these countries, and are often | very important in less developed countries. In a closed loop system, all customers in the system have accounts with a single payment service provider (which may be a bank) or with a small number payment service providers In these systems, purchase or payment transactions involve direct transfers between customer accounts, which are issued by the payment service provider. payments did not support transfers from a closed-loop account to an open-loop account, and the utility of closed-loop systems has therefore been somewhat limited.
    BRIEF DESCRIPTION OF THE DRAWINGS The aspects and advantages of some embodiments of the present invention, and the way in which they are obtained, will be more easily evident by considering the detailed description presented below of the invention, made in conjunction with the drawings in annex, which illustrate the preferred and exemplary embodiments and which are not necessarily drawn to scale, in which: Figure 1 is a block diagram, which illustrates a transaction control system, according to the aspects of this invention; Figure 2 is a block diagram representation of a computer, which performs functions for interconnecting a closed loop payment system as an open loop payment system, as part of the system in Figure 1, and according to aspects of this invention; Figure 3 is a block diagram representation of another
    . computer, which is part of the system in Figure 1, this computer is running. functions of the open loop payment system, in accordance with the aspects of the present invention; Figures 4A and 4B together form a flow chart, which illustrates a process that can be conducted in the system of Figure 1; Figure 5 is a flowchart, illustrating another process, which can be carried out in the system in Figure 1; Figure 6 is a flow chart, illustrating yet another process, Ú that can be conducted in the system of Figure 1; Figure 7 is an alternative block diagram representation of the transaction control system of Figure 1; and Figure 8 is a flow chart, illustrating another process, which: 'can be performed in the system of Figures 7/1. . DETAILED DESCRIPTION In general and for the purpose of introducing concepts of the embodiments of the present invention, a payment gate service provides an interconnection between a closed loop payment system and an open loop payment system.
    A closed loop system user can establish an imaginary account with the open loop system, which the user can access via the closed loop system.
    For example, in a typical transaction, the user may ask the closed loop system to facilitate a purchase transaction with a dealer, who is not a member of the closed loop system.
    It can be considered that, like most traders, the trader in question has a relationship with an acquiring bank, so that the trader can accept payments in the open loop system.
    When requesting the transaction, the user can operate a mobile device, for communication with the closed loop system.
    Orders / communication can identify or by their closed loop counter identifier (or the user can be automatically identified for the | closed loop system), and can also identify the dealer to whom the payment will be made, as well as the amount of the transaction.
    The closed loop system (a / K / a, "provider of payment services
    . payment ") can then transmit a transaction request to the payment port. A transfer of funds to support the requested transaction 'can occur from the user's electronic component account to the account: imaginary, which can be accessed in the loop system The payment port (acting as a proxy for the dealer) can initiate a fairly conventional open loop transaction authorization request for the acquiring bank to the nominated dealer. The transaction authorization request can identify the imaginary account open loop of the user as the account to be debited for the transaction The transaction authorization request can be forwarded through the payment system.Open loop of the acquiring bank, back to the payment port, in the o and its role as a proxy for the customer account issuing FI In the payment system and / or the payment gateway, business rules can be applied to determine ransom will be approved. If approval is guaranteed, the payment gateway can debit the transaction from the user's imaginary account (open loop system), and can issue a transaction authorization response back to the open loop payment system. The transaction authorization response can be returned from the open loop payment system to the payment port, then acting as a proxy for the dealer. The dealer can be informed of the approval of the transaction directly from the payment gateway or by the payment service provider. In this case, or otherwise, the payment gateway can inform the payment service provider of the approval of the transaction, and the payment service provider can then provide adequate notification to the user's mobile device that the transaction has been completed. . , In cases where the transaction is declined, the transfer of funds from the user's closed loop system account to the imaginary account can be reversed.
    With this provision, a user, who has an account in a closed loop system, is allowed to use his closed loop system account to initiate a payment to a dealer, who is not a member
    SS 6/29 - closed loop system.
    In this way, the utility of the user's closed loop system account is greatly increased.
    Ú Furthermore, the routing of the open loop transaction authorization request by the acquirer from the dealer to the open loop system facilitates the payment and settlement for the trader, while allowing the application of the reversal procedures in the transaction. conventional transactions, accounting, dispute management, exception management ie other functional aspects provided by the open loop system. Figure 1 is a block diagram illustrating a transaction process according to aspects of the present invention.
    The various components shown in Figure 1, and discussed below, can be a subset of a larger system, indicated generically by reference number 100, to facilitate payments to dealers using system accounts. closed-loop systems in which traders are not members.
    In the exemplary embodiment illustrated in Figure 1, only the components of system 100, which operate with respect to a single transaction, are shown.
    System 100 includes a dealer device 102, which can be, for example, a properly programmed POS terminal or mobile phone or a PDA (personal digital assistant), or a personal computing device with communication capabilities. (These two possible embodiments of the dealer device may, for example, be particularly suitable for dealers who operate without a fixed place of business.) If the dealer device is a POS terminal, it may be operable in a conventional manner, while also providing functionality, which contributes to the new transaction flow illustrated in Figure 1. The POS terminal can be operated in any type of commercial establishment or retail store, including from a "small business" operation "to a large store, which is part of a chain of retail megastores. | Among other capabilities, dealer device 102 can display transaction information, which will be read by the customer (do not show
    CCC 7/29 already displayed) and manually entered by the customer on his mobile device 104.. For example, the dealer device can display the total amount related to the transaction, and a dealer identification number. Alternative-. In addition, the dealer ID can be displayed permanently on a label affixed to the dealer device 102. In other embodiments, the dealer device 102 may be able to transmit the transaction information to the client device 104. The transmission the transaction information from the dealer device 102 to the client device 7 104 can be via wireless communication, such as by NFC (communication in nearby fields) or, alternatively, it can be via -. through a mobile phone network using text messaging, or ao The client mobile device 104 can, for example, a mobile phone with capabilities to initiate payment transactions face to face with a closed loop payment service provider. As an alternative, the client mobile device 104 can be a PDA with communication capabilities. In some embodiments, the customer's mobile device may initiate a payment transaction by interacting with a website on the network operated by the payment service provider (represented by block 106 in Figure 1).
    In Figure 1, blocks 108, 110 and 112 represent, respectively, the payment gateway, the closed loop system authorization system and the FI acquiring the dealer, as mentioned in the first paragraphs of that section of " Detailed Description". The communication route, through which payment service provider 106 transmits the transaction request to payment port 108, is indicated in 114. The transmission of authorization request 108 to the payment authorization system payment 110 is indicated schematically in 116. The payment request submission of the payment authorization system 110 to FI buyer 112 is indicated in 118. By means of the communication indicated in 120, buyer 112 submits the authorization request back payment authorization system 110. The communication, indicated in 122, represents the
    - authorization request being sent back to the payment port: to 108. 'Communication route 124, in Figure 1, is indicated for sending' payment port 108 message to the dealer device 102, to provide notification that the transaction has been approved. An alternative route to perform the same function is represented by the combination of dashed line arrows 126 and 128. With this route, the notification Ê to the dealer device 102 is retransmitted via the acquiring FI Í
    112. Details of the transaction processing steps men-. above are provided below in conjunction with Figures 4A and 4B. : 'Each block shown in Figure 1 must be understood as representing both a party / entity involved in the transaction and one or more computer systems operated by the party / entity, to generate and / or exchange data necessary for the transaction to occur. It should also be understood that the components shown in Figure 1 can be part of a larger system, capable of handling several transactions, including several simultaneous transactions. For example, system 100 may include multiple dealer devices (operated by multiple dealers), multiple end-user devices, and also a considerable number of acquiring FLs. Furthermore, although only one payment service provider is represented in the drawings, in practice, the payment gateway can interconnect multiple payment providers to the open loop system.
    Both the dealer device 102 and the client mobile device 104 can be conventional in their hardware aspects. In many ways. the operation of such devices, in accordance with the aspects of this invention, may resemble their operation as described in U.S. patent application 1009/0094123, which is incorporated by reference in this specification. In particular, the dealer device 102 and the mobile client device 104 in Figure 1, in this specification, can play roles that are preferably similar to their roles
    O, Ms A RA 9/29 - in the transactions illustrated in Figure 2 or Figure 5 of the pu patent application. blicate '123. There are, however, important differences between transactions Ú of this invention and those of published patent application 123, including the presence in this invention of the payment port 108 and also of the new registration processes performed by the payment port, such as the new 'interactions between the payment gateway and the open loop payment system. Also significantly, in the transactions described in the published patent application '123, an open loop payment system "payment transaction" is employed, whereas, in the present invention, retail sales transactions between dealer and customer (described below. in conjunction with Figures 4A / 4B) employ open loop system "purchase transactions" (a distinction that will be well understood by those skilled in the art). To prove what was stated, the retail sales transactions between dealer and customer, in accordance with the present invention (as illustrated in Figures 4A / 4B), involve an acquiring FI having a relationship with the dealer, while no acquiring FI is present in the transactions described in the published patent application '123. (It should be noted that the published patent application '123 has a common applicant and inventors common with those of the present patent application. It should also be noted that the "payment service provider" referred to in the patent application published patent '123, is not an open loop payment system, and is, in general, very different from the closed loop payment system payment service provider represented by block 106 of Figure 1 in this specification.) A Figure 2 is a block diagram representation of a computer 202, which can perform some or all of the data processing functions to implement payment port 108, shown in Figure 1. Consequently, the computer illustrated in Figure 2 can be referred to as the "payment gateway" computer.
    The payment gateway computer 202 may be conventional in its hardware aspects, but it can be controlled to make it operate in accordance with the aspects of the present invention.
    - The payment port 202 computer may include a pro-. computer stop 200, operationally coupled to a communication device 201, a storage device 204, an input device 206 and an output device 208. The computer processor 200 may consist of one or more conventional processors. The processor 200 operates to perform executable steps per processor, contained in the program instructions described below, in order to control the payment port computer 202, to provide the desired functionality. The communication device 201 can be used to facilitate: communication with, for example, other devices (such as one or more 'computers, which constitute the payment authorization system 110 o (Figure 1), or a computer operated by the provider payment service providers 106). The input device 7206 can comprise one or more of any type of peripheral device, typically used to input data into a computer. For example, input device 206 may include a keyboard and a mouse. Output device 208 may comprise, for example, a monitor and / or a printer.
    Storage device 204 may comprise any suitable information storage device, including combinations of magnetic storage devices (e.g., magnetic tape and hard disk drives), optical storage devices such as CDs and / or DVDs, and / or semiconductor memory devices, such as Random Access Memory (RAM) devices and Exclusive Reading Memory (ROM) devices, as well as the so-called instant memory.
    The storage device 204 stores one or more programs to control the processor 200. The programs comprise program instructions, which contain process steps executable by the payment gateway computer processor 202, including, in some cases, processing steps. processes that constitute processes provided in accordance with the principles of the present invention, as described in more
    . 11/29 - details below. 'Programs may include an application 210, which is for dealing with individual transactions, as described in this specification. 'The operational details of the transaction handling application 210 will be discussed below, particularly with reference to Figures 4A / 4B, 5 and 8A / BB.
    The storage device 204 can also store Ê an application 212 to map customer identifiers of alternative names (for example, customer account numbers to the closed loop payment system) on the “imaginary account” identifiers of sis-, corresponding open loop theme.: Another application, which can be stored by the storage device 204, is indicated by block 214 and can perform functions in which the payment gateway computer 202 serves in a "pro" role - dealer curator ", as described in this specification.
    In addition, application program 216 - also stored in storage device 204 - can perform functions in which the payment gateway computer 202 serves as a "issuer proxy" role, also as described in this specification.
    The storage device 204 can also store an application program 218, which applies (and can also incorporate) one or more commercial papers, by which the payment gateway computer 202 can determine whether to approve or deny individual transactions, which are submitted to the payment gateway computer 202. Reference number 220 in Figure 2 identifies one or more databases, which are maintained by the payment gateway computer 202 on storage device 204. Among these databases there may be a consumer account holder (imaginary account) database, dealer database and transaction database.
    Payment port 202 computer application programs, as described above, can be combined in some con-
    CCEE ——-—-—---. M — p —-- o-n saves 12/29. accretions, as convenient, in one, two or more application programs. dog.
    In addition, storage device 204 can store other programs, such as one or more operating systems, device units, database control software, network hosting software, etc.
    Figure 3 is a block diagram of a computer 302, which is operated to perform one or more functions of the payment authorization system 110 (Figure 1). Consequently, computer 302 can be referred to as the "payment authorization system computer 302". The computer hardware architecture of the payment authorization system 302 can be conventional, and can be the same as: computer of the payment port 202. Thus, the description presented above the hardware aspects of the payment port computer 202 is equally applicable to the computer hardware aspects of the payment authorization system 302. However, the following description is provided to summarize the hardware components of the 302 payment authorization system computer. The 302 payment authorization system computer may include a processor 300, which communicates with a communication device. 301, a storage device 304, an input device 306 and an output device 308. Storage device 304 can store a application 310, which controls the computer of the payment authorization system 302 for the purpose of routing transactions (for example, authorization requests and authorization responses) within the payment authorization system 110. Some aspects of the payment application program transaction routines 310 are described below in conjunction with Figure 6. Furthermore, storage device 304 can store (in some embodiments) an application program 312, which controls the payment authorization system's computer 302, to make determinations whether to approve or deny requests for authorization of individual transactions.
    * Reference number 314 in Figure 3 identifies one or more. databases, which are maintained by the payment authorization system computer 302 on storage device 304, For example, 7 to one or more databases 314 may include a transaction database. In addition, the storage device 304 can store other programs, such as one or more operating systems, device units, network hosting software, etc. 7 Figures 4A and 4B together form a flowchart, which illustrates a process, which can be executed in system 100, and shows, more "particularly, a process which can be executed in the transaction by the payment gateway computer 202. It should be if the purpose and function of the exemplary transaction, illustrated by Figures 44 / 4B, is considered to be - to implement a purchase by a closed-loop account holder (end user) in a retail store operated by a dealer , which is not an element of the closed loop system. The end user was also considered to be involved with payment port 108, so he established an "imaginary account" for the purposes of open loop system transactions, as described in this descriptive report. It is also considered that the end user operates a mobile device (for example, device 104, Figure 1), such as a mobile phone, which is programmed to assist in facilitating payment transactions / purchase through communications with payment service provider 106, which operates the closed loop payment system, with which the end user is associated.
    With reference to Figure 4A, the process begins at 402, with the payment gateway computer 202 receiving an order for a transaction from the payment service provider 106. The genesis for the transaction request may have been an interaction between the mobile device 104 and dealer device 102, for the purpose of facilitating the purchase of the - end user of one or more items on the display of a retail store, in which dealer device 102 is located. As part of the interaction, dealer device 102 may have communicated to the device
    MMMrr ——-—. Ss 14/29 - end user's mobile 104 a total monetary amount (the transaction amount) due to the proposed purchase, and an identifier that identifies the deal for the purposes of the transactions conducted through payment gateway 108 and / or 7 through payment authorization system 110. In some embodiments, the identifier can also identify dealer device 102, considering that it is one of several operated by the dealer. (Alternatively, a separate dealer device can be provided in addition to the dealer device.) An authentication / encryption protocol can protect communication between dealer device 102 and mobile device 104. In some embodiments, communication it is by means of a short-range communication protocol, such as communication in close fields ("NFC"). In other cases, communication Ú with the mobile device may be via a mobile phone network | - (not shown), to which the mobile device 140 is associated (that is, the dealer device 102 can send a text message, or other data message, via the mobile phone system to the mobile device 104 ). The end user, via the mobile device 104, can transmit a request for the transaction to the payment service provider 106. The order, as received at the payment service provider 106, may include the dealer identifier / payment identifier. trading device, the value of the transaction, and some form of identification of the end user.
    This can be, for example, the end user open loop system account identifier (for example, stored on, and transmitted from, mobile device 104) and / or a mobile phone system identifier to the mobile device, automatically provided by the mobile phone system to the payment service provider.
    Upon receiving the transaction request from the mobile device 104, the payment service provider 106 can generate the order, which will be sent to the payment port computer 202 (that is, the order referred to at 402 in Figure 44) . In doing so, payment service provider 106, if necessary, can map the end user identifier
    - the end user account number in the fe- loop payment system. called by payment service provider 106. (This may be unnecessary if (a) the order sent by the mobile device 104, included in the end user's closed loop payment system account number, or ( b) the operation of the payment port 202 computer is such that it accepts the end user's mobile device identifier as the "alternate name" identifier for the end user.) It must be considered that the authentication and encryption protocols - cation can be included in the communication between the mobile device 104 and the payment service provider 106, and between the payment service provider. payment 106 and the payment gateway computer 202. With reference again to Figure 44, block 404 follows' block 402. In block 404, the payment gateway computer 202 maps. the end user's "alternate name" identifier (that is, the end user's closed loop system account number, or the identifier associated with the end user's mobile device, as may be the case) in the account for the "imaginary account" assigned to the end user in the open loop payment system.
    The open loop system account number can be in the same format as a conventional credit or debit card account number - that is, 16 - 19 digits for the main open loop payment systems.
    Decision block 406 then follows block 404. In decision block 406, the payment gateway computer 202 determines whether the mapping operation 404 resulted in a mapping in an open-loop system account number. (That is, the payment gateway computer 202 can determine whether the user's alias identifier is mapped to a valid entry in an end user database, stored on the payment gateway computer 202.) If the payment port computer 202 makes a positive determination in decision block 406 (that is, if payment port computer 202 determines that the alias identifier identifies a valid end user associated with the payment port), then the block 408 follows the
    NS SS OSS to SS NS ease 16/29. decision block 406.. In block 408, the payment gateway computer 202 charges 'a stored value account (which stores funds related to the payment service provider' 106) for the amount of the purchase transaction requested, and concurrently, in 410, the payment computer payment port 202 credits the purchase transaction amount to the user's imaginary account, to support the proposed payment to the dealer in the open loop system. Then, at 412, the payment gateway computer 202 generates a purchase transaction authorization request 7 according to the format requirements of the open loop system. For example, the purchase order authorization form can follow the known pattern: | as "ISO 8583" and may include the necessary data elements in this format, including the trader's identifier, the purchase transaction amount and the account number (PAN - "primary account number"), which identifies the imaginary account of the end user's open loop system. Then, in 414, the payment gateway computer 202 can transmit the authorization request to payment authorization system 110. In doing so, the payment gateway computer 202 acts as a proxy for the dealer.
    In some embodiments, the payment authorization system 110 may operate so that it routes the authorization request from the payment port computer 202 to the acquirer 112 to the dealer. (The operation of the payment authorization system 110, in conjunction with the transaction, is described in more detail below in conjunction with Figure 6) The acquirer 112 then forwards the authorization request to the payment authorization system 110, for routing to the entity in relation to the authorization request. According to aspects of the invention, that entity is payment port 108 / payment port computer 202. Consequently, payment authorization system 110 relays the authorization request back to the payment port computer 202 , which then acts as a proxy for the issuer in determining whether the authorization request will be approved
    Aa 17/29 - or denied.
    Block 416 in Figure 4A represents the port computer. payment 202 receiving the authorization request back from the 'payment authorization 110' system. 'The imaginary account of the end user's open loop system has been credited with funds to cover the requested transaction, so it is highly unlikely that the transaction needs to be denied for insufficient funds.
    However, and as indicated at 418 in Figure 4B, the payment gateway computer 202 may, in some embodiments, apply - one or more business rules to determine whether there are other reasons for denying a transaction. (Alternatively, business rules - or some of them. - can be applied in the payment authorization system 110 instead of 'the payment gateway computer 202.) For example, an applicable' business rule may prevent payments to a certain class or dealer - classes, such as casinos or betting network sites.
    Another business rule applicable for recommending a "speed" limit (ie, a limit on the number of transactions for a given account in a predetermined period of time) and / or a limit on the total dollar value of transactions in a predetermined period of time.
    It may also be the case that the transaction may be denied due to a data mismatch, a format error, or a lack of information in one or more required data fields.
    Block 420 in Figure 4B follows block 418. In block 420, the payment gateway computer 202 generates and transmits an authorization response to payment authorization system 110. The authorization response can be in a conventional format for the transaction authorization responses in an open loop payment system, and therefore indicates that the authorization request is approved or denied.
    Payment authorization system 110 then returns the authorization response to payment port computer 202, which will act as a proxy for the dealer.
    Block 422 represents the payment port computer 202 receiving the return of the authorization response from the payment authorization system 110. |
    CCC 18/29, In decision block 424, the payment gateway computer. 202, acting as the dealer's proxy, determines whether the authorization response indicates approval of the transaction authorization request.
    By doing this, then block 426 follows decision block 424. On payment gateway computer 426.0 transmits approval to dealer device 102. This can occur directly, or indirectly, through the buyer from dealer 112 and / or the dealer's transaction processing system (not shown). Furthermore, in 428, payment gateway computer 202 transmits an indication to the payment service provider 102 that the transaction has been approved. . Upon receipt of the approval message on the 'dealer 102' device, the purchase transaction can be consummated, and the end user authorized to leave the retail store with their purchase.
    Payment service provider 106, when notified of the approval of the payment transaction on the payment port 202 computer, can implement or finalize a debit from the closed loop system account for the purchase amount.
    In addition, payment service provider 106 may transmit a message to the end user 104's mobile device, to notify the end user that the payment transaction has been completed.
    With reference again to decision block 406 in Figure 4A, if a negative determination is made on that decision block (that is, if the end user does not map to a valid open loop imaginary account number), then the computer payment gateway 202 can generate a "transaction denied" response, as indicated at 430 in Figure 4A.
    The payment gateway computer 202 can send appropriate messages to indicate that the payment service provider 106, and / or the merchant device 102, has been denied the transaction. With reference again to decision block 424 in Figure 4B, if a negative determination is made in that decision block (that is, if the authorization response indicates that the authorization request was denied), then block 432 (Figure 4B) follows decision block 424. In block 432 , the processing of blocks 408 and 410 is inverted, so that the value
    EE - 19/29 "of the transaction is debited from the imaginary open loop system account and. Credited back to the value storage account for the payment service provider 106. The process then proceeds from block 432, in 'Figure 4B, for block 430, in Figure 4A, so that the payment port 202 computer sends "transaction denied" messages to payment service provider 106 and / or to the dealer's dealer / acquirer.
    Figure 5 is a flow chart that illustrates the settlement process - in system 100 for the transaction illustrated in Figures 4A / 4B. Block 502 indicates the start of the settlement process. This can occur at the end of a working day and / or at predetermined points in: time during the day. Branch 503 of block 502 leads to block 504. In Ú block 504, the payment gateway computer 202 aggregates credit and debit file records based on the master transaction counter for payment service provider 106, and, based on individual end user accounts, for payment service provider associates
    106. Then, in 506, the payment port 202 computer performs a cleaning and "charge" settlement, according to a process that was previously agreed between payment service provider 106 and payment port 108.
    In 508, the payment gateway computer 202 generates an account reconciliation file, which details the cleaning and settlement activity in 506, and sends the account reconciliation file to the payment service provider 106, for processing and any reconciliation required by the payment service provider 106.
    Branch 511 of block 502 leads to block 512. In block 512, the payment port aggregates the debit and credit transactions of the imaginary account, according to open loop system practices. In block 514, the payment gateway computer 202 performs the cleaning and settlement of "encumbrances" processes, in accordance with the commercial rules for the open loop payment system. In 516, the payment port 202 computer generates a cleaning / settlement file, which details the activity
    CC —— 20/29 - cleaning and settlement capacity in 514, according to rules and standards. to the open loop system, and send the cleaning / liquidation file to the open loop network for processing in a 'conventional' manner.
    Figure 6 is a flowchart, which illustrates the operation of the payment authorization system computer 302 (Figure 3), together with the transaction illustrated in Figures 4A / 4B.
    In 602, the payment authorization system computer - 302 receives the authorization request (generated by the payment port computer 202 in 412 in Figure 44) from the acquirer of dealer 112. In * 604, the payment authorization system computer payment 302 relays: the authorization request to the computer of the payment port 202, so that the payment port can serve as an emi- proxy. try for the transaction authorization request. At 606, the payment authorization system computer 302 receives the transaction authorization response, which was transmitted by the payment port computer 202 (at 420 in Figure 4B). At 608, the payment authorization system computer 302 returns the transaction authorization response to the payment port computer 202, so that the payment port computer 202 can serve as a dealer proxy to receive the response authorization.
    In the transaction processes described above in conjunction with Figures 4A / 4B, 5 and 6, an end-user open loop payment system account is used for payment to a dealer, which is not associated with the closed loop system . The transaction is implemented through an open loop payment system that the dealer is associated with as a transaction acceptor. A payment gateway provides an interface between the closed loop system and the open loop system, and imports funds for the transaction from the closed loop system to the open loop system. With transaction routing through the dealer's acquirer, and with the payment port serving as both the dealer's attorney and the issuer's attorney, payment to the trader
    CSS 21/29 - ante is facilitated by the dealer acquirer and the conventional functionality of the open loop system, for cancellations (when necessary), accounting, reconciliation, dispute management and exception management, they are all considered, if necessary.
    A cooperative bank can serve as the issuer for imaginary accounts, in which transactions are debited by the payment gateway. Alternatively, the payment gateway itself can serve as an issuer. In some embodiments, the payment gateway can be affiliated with and / or operated by the network operator for the payment system - open deloop. In some embodiments, the payment service provider may serve as the issuer of the imaginary accounts. End users can be directly involved, on an individual basis, with the payment port Ú, or they can be massively involved in imaginary accounts - by the payment service provider. In some embodiments, end users are not payment cards issued to access the imaginary account, and can, in fact, only use the imaginary account through transaction requests made to the payment service provider. Consequently, the end user may not receive any indication regarding the imaginary account apart from the indications presented to the end user by the payment service provider for the end user's closed loop system account. In short, the imaginary account can work with only one way for payments originating from the end user's closed loop system account to the open loop payment system. In other embodiments, the imaginary account can also serve as a fully functioning credit or debit card account. Figure 7 is an alternative block diagram representation of the transaction handling system 100, shown in Figure 1. Figure 7 represents an additional functionality of system 100, so that system 100 supports person-to-person shipments, in addition to customer-to-dealer payments, as discussed above in conjunction with Figures 1, 4A / 4B, 5 and 6. For a slightly more general discussion of shipments from person to person, reference is made to the patent application
    - published U.S. 2008/0249929, which has common inventors and is the same: applicant for this patent application. (The published patent application '929 is' incorporated into this specification by reference.) One should consider "for the purposes of the shipping transaction illustrated in Figure 7 (and also for the purposes of the discussion below Figures 8A / 8B), that the intended recipient of the remittance occupies an open-loop payment card account, but is not a member of the closed-loop payment system: closed, operated by the payment service provider, which is represented in Figure 7 (as in Figure 1) by block 106. As in the case of Figure 1, the system components shown in Figure 7 are those that 7] operate with respect to a single transaction, with system 100 also being constituted. by several other components.] As in Figure 1, block 104 in Figure 7 represents a mobile device (for example, a mobile phone), operated by an individual end user, who is a member of the payment service provider 106 For the delivery transaction, the user has nal can operate the mobile device 104, for communication with the payment service provider 106, to initiate the remittance transaction.
    Blocks 108 and 110 again represent, respectively, the payment gateway and the payment authorization system of the open loop system.
    Block 702 in Figure 7 represents the financial institution (FI), which is the issuer of the open loop payment card account, which belongs to the recipient for the remittance transaction.
    Reference numbers 703, 704, 706 and 708 represent routes of communication between the system components involved in the transaction in question.
    The details of the communications performed between the components of the system will be described below together with Figure 8. Again, as was the case with Figure 1, each block shown in Figure 7 must be understood as representing both a part / entity involved in the remittance transaction and one or more computer systems operated by the party / entity, to generate and / or exchange data necessary for the remittance transaction to occur.
    The RA 23/29 - Figure 8 is a flow chart that illustrates a process, which it can. be conducted in system 100, to implement the remittance transaction 'mentioned above in conjunction with Figure 7. More particularly, Figure 8 shows a process, which can be conducted in controlling the transaction by the gateway computer. payment 202, serving as a functional component of payment port 108, shown in Figure 7.
    For the purposes of Figure 8, the issuer / end user of the remittance has previously operated its mobile device 104 (Figure 7), to - transmit to the payment service provider 106 an order for a remittance transaction, to be financed loop system account: closed. The order, as received at the payment service provider '106, may include the remittance amount (transaction amount), the information] that identifies the recipient of the remittance, and some form of identification of the - sender. This information can be, for example, the identifier of the sender's closed loop system account (for example, stored on and transmitted from the mobile device 104 and / or an identifier from the mobile phone system to the mobile device, provided automatically by the system phone provider to the payment service provider). The sender's request to payment service provider 106 may identify the recipient by the payment card account of the open loop system or by an alternate name identifier, such as the recipient's mobile phone number. In other other embodiments, the sender may have access to a profile that the sender previously stored at the payment service provider 106, to facilitate remittances and to be able to select the recipient from among one or more proposed remittance containers, stored in the sender's profile.
    Upon receiving the remittance transaction request from the mobile device 104, the payment service provider 106 may generate an order for the remittance transaction, for transmission from the payment service provider 106 to the payment port computer 202. (O receipt by the payment port 202 computer of the payment service provider 106 remittance transaction request is indicated in the block
    . 802 in Figure 8). For generating the remittance transaction order, the pro-. payment service provider 106, if necessary, can map the identifier for the sender / end user to the end user's account number in the closed loop payment system operated by payment service provider 106. (This may be unnecessary if (a) the remittance order sent by the mobile device 104 has included the closed loop payment system account number, or (b) the operation of the payment gateway computer 202 is such that it accepts the identifier of the sender's mobile device as the "alternate name" identifier for the sender.). It should be considered that authentication and encryption protocols can be included in the communication between the mobile device 104 and: the payment service provider 106, and between the payment service provider 106 and the gateway computer. payment 202. Referring again to Figure 8, block 804 follows block 802. At block 804, the payment gateway computer 202 maps the sender's alias identifier (that is, the payment system account number) sender's closed loop or the identifier associated with the sender's mobile device, as may be the case) in the account number for the "imaginary account" assigned to the sender in the open loop payment system. . Decision block 806 then follows block 804. In decision block 806, the payment gateway computer 202 determines whether the mapping operation in 804 resulted in a mapping to an open loop system account number of valid end user. (That is, the payment port 202 computer can determine whether the sender's alias identifier is mapped into a valid entry in the end user database, stored on the payment port computer 202.) If the payment port computer 202 makes a positive determination in decision block 806 (that is, if the payment port computer 202 determines that the alias identifier identifies a valid end user involved with the port payment),
    - so block 808 follows decision block 806. - In block 808, the payment gateway computer 202 debits Ú a stored securities account (which stores funds for payment service provider 106) to the value of the requested remittance transaction, and, concurrently, in 810, the payment port 202 computer credits the remittance transaction amount to the sender's imaginary account, to support the transfer of the proposed funds to the recipient. Then, in 812, the computer at: payment port 202 generates an authorization request for a payment transaction in the open loop system. As used in this paragraph, the term "transaction". payment term "is a term of the technique used in conjunction with open loop payment systems, and has the same meaning discussed in paragraph 0085 of the published patent application '929 referred to above. The application for - authorization may be in a format that follows the standard known as "ISO 8583" and can include necessary data elements in that format, including the payment transaction amount and the payment card account number (PAN) for the payment card account of open loop system, to which the funds transfer will be made. (If necessary, the payment gateway computer 202 may have previously mapped the recipient's alternative name identifier to the recipient's PAN; alternatively, the order received by the payment gateway computer 202 may have included the recipient's PAN in it.) Then, in 814, the payment gateway computer 202 can transmit the payment transaction authorization request to the system payment authorization number 110. —When doing this, the payment port 202 computer is acting as a home financial institution for the payment transaction.
    Payment authorization system 110 then routes the authorization request to receiving FI 702 (Figure 7), according to conventional business practices and rules. Receiving FI 702 processes the authorization request in a conventional manner (typically for the purpose of determining whether the recipient's PAN in the order is valid), and then transmits an authorization response to approve or deny the request
    . authorization. (In some embodiments, the receiving FI 702, the payment gateway computer 202 or another entity shown in Figure: 7 can also apply business rules, for example, speed rules - to determine whether the shipment requested was allowed.) The authorization response is then routed from receiving Fl 702, via payment authorization system 110, to the payment port computer
    202. The receipt of the authorization response by the computer of the Ê payment port 202 is indicated at 816 in Figure 8. .. Decision block 818 in Figure 8 follows block 816. In decision block 818, the computer of the payment gateway payment 202 determines. whether the authorization response indicates that the remittance / payment transaction authorization request has been approved. If so, block 820 follows: following decision block 818. In block 820, the port computer of: payment 202 transmits to the payment service provider 106 an indication that the remittance transaction has been approved. Payment service provider 106, upon being notified by the payment gateway computer 202 of approval of the remittance transaction, can transmit a message to the sender's mobile device 104 to notify the sender that the remittance transaction has been completed . In some embodiments, the sender, and / or another entity involved in the remittance transaction, may notify the recipient that the funds transfer has taken place. With reference again to decision block 806 in Figure 8, if a negative determination is made on that decision block (that is, if the sender's alias is not mapped to a valid open loop imaginary account number), then the payment gateway computer 202 can generate a "transaction denied" response, as shown in 822 in Figure 8. The payment gateway computer 202 can send the denial response to the payment service provider.
    106. With reference again to decision block 818 in Figure 8, if a negative determination is made in that decision block (that is, if the
    - authorization response indicates that the transaction authorization request for. payment was denied), then block 824 follows decision block '818. In block 824, the processing of blocks 808 and 810 is reversed, so that the value of the remittance transaction is debited from the imaginary payment system account. open loop of the sender and credited back to the storage account for payment service provider 106. The process then proceeds from block 824 to block 822, so that the payment port computer 202 sends a "transaction-denied" response to payment service provider 106. Settlement of the payment transaction, which implements the requested order, can happen as described in conjunction with Figure 5. 'In some embodiments, the shipping container may be] a dealer with whom the shipping sender is dealing with a retail purchase transaction, and the shipping transaction can implement payment for the purchase transaction in a manner related to the transaction illustrated in Figure 9 of the published patent application '123 referred to above.
    It was noted above that system 100 may include more than one payment service provider connected to the open loop system by the payment port.
    In some embodiments, end users have accounts in more than one closed loop system, and all end user closed loop system accounts can be mapped through the payment gateway into an imaginary single open loop system account.
    In some embodiments, transactions in open loop systems, which will be debited from an end user closed loop system account, can be initiated by a dealer using the end user closed loop system account number as an alternative stops the end user open loop system PAN.
    This transaction may involve, for example, routing an authorization request from the dealer to the acquirer, and then from the acquirer to the payment gateway, to map the alternative to the end-user PAN.
    The payment port po-. also to obtain the necessary funds for the transaction, to credit in the
    . imaginary account of an end-user open loop system, from the payment service provider.
    i The payment gateway can also, in some embodiments, facilitate the payment of accounts from account accounts of the —loop closed-end system accounts to billing entities through the open loop payment system. As used in this specification and in the appended claims, the term "computer" should be understood to cover - a single computer or two or more computers communicating with each other - as used in this specification and in the appended claims: , the term "processor" should be understood as encompassing a single processor or two or more processors in communication "with each other.
    As used in this specification and the appended claims, the term "memory" is to be understood as covering a single memory or storage device or two or more memories or storage devices.
    The flowcharts and their descriptions in this specification should not be understood as recommending a fixed order of method steps described in this specification. Instead, method steps can be conducted in any order that is practical.
    As used in this specification and in the appended claims, the term "payment card account" includes an account for: credit card or a deposit account, which the account holder can access by using a payment card. debt. The term "payment card account number" includes a number, which identifies a payment card account or a number conducted by a payment card, or a number that is used to identify an account in a payment system that controls debit and / or credit card transactions, or to route a transaction to a payment system that does. controls debit and / or credit card transactions.
    The term . 'payment card' includes a credit card or a debit card '(including a prepaid debit card). The term "payment card account" also includes an account to which a payment card account number is assigned.
    In this way, a payment card account can include an account, in which payment transactions can be routed through a payment system, which controls debit and / or credit card transactions, even if the account in question is not - acceptable to be charged for purchase transactions or other transactions.
    A payment card account can also include an account - from which payment transactions can be routed through a: payment system, which controls debit and / or credit card transactions, even if the account in question is not the one normally used, or - is not acceptable, to be charged for purchase transactions.
    Although the present invention has been described together. with specific exemplary embodiments, it should be understood that various changes, substitutions and alterations, evident to those skilled in the art, can be made in the described embodiments, without departing from the spirit and scope of the invention, as presented in the claims attached.
    权利要求:
    Claims (28)
    [1]
    V7. CLAIMS R 1. Process, comprising:: receiving, on a transaction processing computer, 7 an order for a transaction from a payment service provider, the order including: (a) an end user identifier indicating an end user that has a closed loop system account; (b) a dealer identifier; and (c) a transaction amount; the transaction processing computer mapping the end user identifier to an account number on the payment card system; . receive, from said payment service provider, funds i-: equal to said transaction amount; 'credit said funds, equal to said transaction amount, into - a payment card system account, identified by the number of counted payment card system; transmit a payment card transaction authorization request from the transaction processing computer to an acquirer, the acquirer having a relationship with the dealer identified by the dealer's identifier, the transaction authorization request from the payment system payment card including said account number of the payment card system and indicating said transaction amount; receiving, on the transaction processing computer, a version of said transaction authorization request from the retransmitted payment card system by a payment card system transaction authorization system; debit said transaction amount to said payment card system account; and transmitting, from the transaction processing computer, to the payment card system authorization system, a response to every payment card system transaction authorization request.
    [2]
    A process according to claim 1, comprising
    " still: . determine by said transaction processing computer, based on at least one commercial rule, whether to approve the transaction authorization request 7 received retransmitted by the payment card system authorization system.
    [3]
    A process according to claim 2, wherein at least one commercial rule includes a speed rule, which limits a number of transactions for a predetermined period of time. |
    [4]
    4. Process according to claim 1, in which the version received of the retransmitted transaction authorization request indicates that the. payment card system authorization system approved the authorization request.
    [5]
    5. Process according to claim 1, in which the: payment card system account is an imaginary account, which does not result in an end user being charged.
    [6]
    6. Process according to claim 1, further comprising: transmitting an indication from the transaction processing computer to the dealer that the transaction has been approved.
    [7]
    7. Process according to claim 1, further comprising: transmitting from the transaction processing computer to the acquirer an indication that the transaction has been approved.
    [8]
    8. Process according to claim 1, further comprising: receiving, from the authorization system of the payment card system, a return of the response to said transaction authorization request.
    [9]
    9. Process according to claim 8, wherein the payment card authorization system does not send the response to the transaction authorization request to the acquirer.
    [10]
    10. Process according to claim 1, wherein the identifier
    [11]
    - End user indicator is: (a) an identifier for the loop system account. closed end user, and (b) an identifier for a mobile device operated by the end user. 11. Process according to claim 1, in which the transaction processing computer transmits the transaction authorization request to the acquirer through the payment card system authorization system.
    [12]
    12. Apparatus, comprising: a processor; e: a memory in communication with the processor and storage. nating the program instructions, the processor acting with the: program instructions to: Ú receive an order for a transaction from a payment service provider - the order including: (a) an end user identifier —indicates an end user who has a closed loop account, (b) a dealer identifier, and (c) a transaction amount; map the end user identifier to an account number in the payment card system; receive, from said payment service provider, funds i- —any amount of the transaction amount; credit said funds, equal to said transaction amount, in an account of the payment card system identified by the account number of the payment card system; transmit a request for transaction authorization from the payment card system to an acquirer, the acquirer having a relationship with a dealer identified by the dealer identifier, the transaction authorization request from the payment card system including said account number the payment card system and indicating the said value of the transaction; receiving a version of said payment card transaction authorization request retransmitted by a payment card authorization system;
    . debit said transaction amount to the card and payment system account; and Ú transmit to the payment card system authorization system a response to said payment card transaction authorization request.
    [13]
    13. Apparatus according to claim 12, in which the processor is still active with the program instructions to: determine, based on a commercial rule, whether to approve the transaction authorization request received by the authorization system payment card system. -
    [14]
    Apparatus according to claim 13, wherein the at least one commercial rule includes a speed rule, which limits a number of transactions for a predetermined period of time. :
    [15]
    15. Apparatus according to claim 12, in which the version received from the relayed transaction authorization request indicates that the payment card system authorization system has approved the authorization request.
    [16]
    16. Apparatus according to claim 12, wherein the payment card system account is an imaginary account, which does not result in an end user being charged.
    [17]
    17. Apparatus according to claim 12, in which the processor is still active with the program instructions to: transmit to the dealer an indication that the transaction has been approved.
    [18]
    18. Apparatus according to claim 12, in which the processor is still active with the program instructions to: transmit to the purchaser an indication that the transaction has been approved.
    [19]
    19. Apparatus according to claim 12, in which the programmer is still active with the program instructions to: receive, from the authorization system of the payment card system, a return of the response to said authorization request of transaction
    [20]
    JS tion. and 20. Apparatus according to claim 19, wherein the payment card system authorization system does not send response 7 to the transaction authorization request to the acquirer.
    [21]
    21. Apparatus according to claim 12, wherein the end user identifier is: (a) an identifier for the closed loop system account of the end user, and (b) an identifier for a mobile device | operated by the end user. :
    [22]
    Apparatus according to claim 12, wherein the processor transmits the transaction authorization request to the acquirer via the - payment card system authorization system, '
    [23]
    23. Process, comprising:: receiving, on a transaction processing computer, * an order for a remittance transaction from a payment service provider, the order including an end user closed loop system account identifier, a container identifier, and a shipment value; the transaction processing computer mapping the end user's closed loop system account identifier to a counted payment card system number; receiving, from said payment service provider, funds equal to said remittance amount; credit said funds, equal to said remittance amount, in a payment card system account, identified by the account number of the payment card system; transmitting a transaction authorization request for a payment transaction to a payment card system to benefit a recipient identified by the recipient identifier; receive, on the transaction processing computer, from the payment card system, a response to the authorization request;
    MM 6/7 - debit the amount of the remittance in said payment card system account; and 'transmit, from the transaction processing computer, to: a payment service provider an indication that said remittance amount has been approved.
    [24]
    24. Process according to claim 23, further comprising Ê: determining by the transaction processing computer, It is based on at least one commercial rule, whether to approve the received transaction authorization request relayed by the authorization system. payment card system. The
    [25]
    25. The process of claim 24, wherein at least one business rule includes a speed rule, which limits one - number of transactions over a predetermined period of time.
    [26]
    26. The process of claim 23, wherein the payment card system account is an imaginary account, which does not result in an end user being charged.
    [27]
    27. Process, comprising: receiving, on a computer from the payment authorization system, a request for authorization of transaction from the payment card system of an acquirer; transmitting, through the computer of the payment authorization system, to a transaction processing computer the transaction authorization request from the payment card system; receive, on the payment processing system's computer from the transaction processing computer, an indication that the payment card system's transaction authorization request has been approved; and return, via the payment authorization system's computer, to the transaction processing computer the said indication that the payment card's transaction authorization request has been approved.
    7M7.
    [28]
    28. The process of claim 27, wherein the computer of the payment authorization system does not transmit said indication to the purchaser.
    : 1/9 | "2 r- 5! $ Ns | NS: == | l le z LR -
    I
    Í! | and. if | 85 and SEE: e | ES5 | Ss sz! : ls =: 1 -. | | - |
    HA l! t o
    AND ! +! [8 - | 2 I = 18 - 2 Ds E! 8! s8s 2 5! Es. ! Ss 3 |! 1 ê À: = | 1 ês + | *
    SE | The
    I and if 1 1 8 L- 3 ê
    ] / 202 206 201 208 Device Device Device Input Communication Output 200] 204 210 Transaction control 22 Pan mapping Far Dealer proxy 26 Issuer proxy 220 Database (s) | FIG. 2
    . 3/9 'VA 306 301 308 | inbound outbound communication 300 304 MM transactions “processing - | - P 'te 2 TH geavoização - | And the ==>> "[monthly | FIG. 3
    - 4/9 7 402 Receive transaction request 404 - Map alternative to pan oO 406 430: io validi No valid user Negative answer Í Yes 408 Dehbitar account PSP 410 Credit imaginary end user account 412 Generate authorization request 414 Transmit to authorization system 416 Receive authorization request retransmitted FIG. 4A
    - 5/9 48 Yes | 420. Transmit authorization response 422 'Receive return of authorization response E 452 No Pr ”eu = Reverse debit / credit Yes 426 Transmit approval (B) to dealer 428 Transmit approval to PSP FIG. 4B
    - 6/9 502 Start process - settlement 503 Ss 504 512 Aggregate PSP RE of records Aggregate records of files “from debit and credit debit and credit transaction files to open loop system accounts 506 su Clear and settle "liens" per agreement with PSP Clear and settle "liens" in accordance with open loop commercial rules 508 516 Generate Ane account reconciliation file.
    Generate cleaning file / for submission to psp settlement according to open loop systems practices FIG. 5
    Receive buyer authorization request: Relay authorization request to payment gateway Receive response to payment gateway authorization | 608 Return authorization response to payment gateway FIG. 6 to “ç> 8/9.
    E m oNW = s 8 to 8 e | es | os 885 sounds 55S Ter vio 8 2 "8 & s be <) as E & 8 Ís 2 ss Es 82 8 ps Í 2 Es à
    If the
    Receive shipping order 804: Map alternative to pick 806 830 No Valid user ao Yes 808 Debit PSP account 810 Credit imaginary end user account 812 Generate authorization request 814 Transmit to authorization system 816 Receive authorization response 818 824 No Reverse debit / Approval PSP / end user credit sm 820 Transmit approval to PSP FIG. 8
    类似技术:
    公开号 | 公开日 | 专利标题
    BR112013001042A2|2020-08-25|money transfer system door service
    CA2366517C|2006-11-07|Person-to-person, person-to-business, business-to-person, and business-to-business financial transaction system
    CN109313764A|2019-02-05|Tokenized system and method are carried out to the Deposit Account Number used at Payment Card receiving station
    US10546287B2|2020-01-28|Closed system processing connection
    BRPI0613951A2|2011-02-22|system and method for re-executing and managing data and financial transactions
    US20030105688A1|2003-06-05|Secure digital escrow account transactions system and method
    US20110055083A1|2011-03-03|System and method of funds transfer using a secure financial account
    TW200830211A|2008-07-16|System and method of managing contactless payment transactions using a mobile communication device as a stored value device
    BRPI0901775A2|2010-09-14|provision of &#34;for&#34; services for mobile phone access to payment card account
    JP2014514656A|2014-06-19|Financial transaction system, financial transaction method and computer program
    IL280420D0|2021-03-25|Systems and methods for facilitating transactions using a digital currency
    BR102012016784A2|2014-12-02|METHODS TO MAKE DISBURSEMENTS FOR ONE OR MORE CONSUMERS AND TO RECEIVE DISBURSEMENTS FROM A BUSINESS PLURALITY THROUGH A PLATFORM, AND, COMPUTER
    US20190095989A1|2019-03-28|Systems and Methods for Managing Accounts in a Financial Services System
    US10621567B2|2020-04-14|Electronic grace period billing
    JP2004234257A|2004-08-19|Detailed receipt transaction audit method, system and program, and recording medium
    RU76485U1|2008-09-20|ELECTRONIC PAYMENT SYSTEM FOR MONEY MANAGEMENT BASED ON UNIVERSAL DEBIT-CREDIT PAYMENT CARDS
    JP2018045446A|2018-03-22|Settlement system, method and program
    BR102019021256A2|2021-04-20|change management method generated from financial transactions between users registered on a remote access platform
    JP2021105776A|2021-07-26|Card-less credit settlement
    KR20030075851A|2003-09-26|Card settlement system and operation method
    Lai2018|Understanding Interbank Real-Time Retail Payment Systems
    KR20080052764A|2008-06-12|System and method for processing payment and program recording medium
    KR20090001953A|2009-01-09|System and method for managing deposit account by using providing real goods for pre-interst and program recording medium
    US8533112B1|2013-09-10|Method and system for providing a digital money infrastructure using mobile telephony
    KR20070088843A|2007-08-30|Integrated settlement method using sms, escrow account and virtual account and recording medium thereof
    同族专利:
    公开号 | 公开日
    MX2013000603A|2013-06-05|
    MX337491B|2016-03-08|
    WO2012009165A1|2012-01-19|
    US20150066756A1|2015-03-05|
    EP2593913A4|2014-03-05|
    US20120016799A1|2012-01-19|
    EP2593913A1|2013-05-22|
    US9767442B2|2017-09-19|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    US20070022375A1|2000-10-19|2007-01-25|David Walker|Apparatus, system, and method for an electronic payment system|
    US7292999B2|2001-03-15|2007-11-06|American Express Travel Related Services Company, Inc.|Online card present transaction|
    US20070203832A1|2006-02-28|2007-08-30|Rene Pierre Babi|Intermediary payment system and method for gaming|
    US20070214080A1|2006-02-28|2007-09-13|Rene Pierre Babi|Intermediary payment system and method|
    US8510223B2|2006-08-03|2013-08-13|The Western Union Company|Money transfer transactions via pre-paid wireless communication devices|
    US7575177B2|2007-10-03|2009-08-18|Mastercard International, Inc.|Dual use payment device|
    US8046268B2|2008-07-14|2011-10-25|Shop Ma, Inc.|Multi-merchant payment system|
    US8631999B2|2009-02-09|2014-01-21|Giftcodes.Com, Llc|System and method for accepting closed loop cards and codes at a merchant point of sale|US8016185B2|2004-07-06|2011-09-13|Visa International Service Association|Money transfer service with authentication|
    WO2011019660A2|2009-08-10|2011-02-17|Visa International Service Association|Systems and methods for enrolling users in a payment service|
    US8924297B2|2011-02-25|2014-12-30|Visa International Service Association|Direct connection systems and methods|
    US20130006810A1|2011-06-30|2013-01-03|Aurelio Elias|Method and system for the execution of non-bank Third Party Services Transactions over Financial Networks through Electronic Terminals utilizing a Non-Depository Virtual Account Management System|
    US9830596B2|2011-11-01|2017-11-28|Stripe, Inc.|Method for conducting a transaction between a merchant site and a customer's electronic device without exposing payment information to a server-side application of the merchant site|
    AU2014256396B2|2013-11-15|2020-08-20|Nyce Payments Network, Llc|Systems and methods for real-time account access|
    US10535064B2|2012-03-19|2020-01-14|Paynet Payments Network, Llc|Systems and methods for real-time account access|
    AU2013235387A1|2012-03-19|2014-10-09|Paynet Payments Network, Llc|Systems and methods for real-time account access|
    US20130282581A1|2012-04-18|2013-10-24|Infosys Limited|Mobile device-based cardless financial transactions|
    US20160155112A1|2012-10-10|2016-06-02|Mastercard International Incorporated|Barcode-triggered payment method and system|
    US20140214649A1|2013-01-25|2014-07-31|Brian J. DuCharme|Pay to any account service|
    US8770478B2|2013-07-11|2014-07-08|Scvngr, Inc.|Payment processing with automatic no-touch mode selection|
    CN105450583B|2014-07-03|2019-07-05|阿里巴巴集团控股有限公司|A kind of method and device of authentification of message|
    CN105446992A|2014-07-08|2016-03-30|阿里巴巴集团控股有限公司|Method and device for building goods object recovery information database and determining value information|
    CN105450411B|2014-08-14|2019-01-08|阿里巴巴集团控股有限公司|The method, apparatus and system of authentication are carried out using card feature|
    CN105719183A|2014-12-03|2016-06-29|阿里巴巴集团控股有限公司|Directional transfer method and apparatus|
    CN105869043A|2015-01-19|2016-08-17|阿里巴巴集团控股有限公司|Disperse hot spot database account transfer-in and transfer-out accounting method and device|
    CN105989467A|2015-02-03|2016-10-05|阿里巴巴集团控股有限公司|Wireless payment method, apparatus, vehicle ride fee check method and system|
    US10410194B1|2015-08-19|2019-09-10|Square, Inc.|Customized tipping flow|
    CN106570009B|2015-10-09|2020-07-28|阿里巴巴集团控股有限公司|Navigation category updating method and device|
    WO2017139688A1|2016-02-12|2017-08-17|D+H Usa Corporation|Peer-to-peer financial transactions using a private distributed ledger|
    CN106127568A|2016-06-15|2016-11-16|中国人民银行清算总中心|The clearing operation queue rescue method of inter-bank payment system and device|
    CN109313766A|2016-06-15|2019-02-05|万事达卡国际公司|The system and method monitored for budget, finance account alert management, remedial action control and fraud|
    SG10201609847PA|2016-11-23|2018-06-28|Mastercard International Inc|System And Method For Processing Payment|
    EP3340143A1|2016-12-22|2018-06-27|Mastercard International Incorporated|Configuring a transaction device|
    US10645175B2|2017-03-30|2020-05-05|Cameros Bay Capital, LLC|Proxy device for routing electronic messages|
    US11042852B1|2017-06-23|2021-06-22|Wells Fargo Bank, N.A.|Sender authenticated remittance via an automatic teller machine|
    US20190197506A1|2017-09-14|2019-06-27|Robert Jay McShirley|Merchant service for real-time settlement apparatus and method|
    US11244322B2|2018-09-18|2022-02-08|Mastercard International Incorporated|Methods and apparatus for chargebacks of push payment transactions|
    WO2020132193A1|2018-12-21|2020-06-25|Visa International Service Association|Method for processing via conditional authorization|
    US11234235B2|2019-04-30|2022-01-25|Bank Of America Corporation|Resource distribution hub generation on a mobile device|
    US11196737B2|2019-04-30|2021-12-07|Bank Of America Corporation|System for secondary authentication via contactless distribution of dynamic resources|
    US10998937B2|2019-04-30|2021-05-04|Bank Of America Corporation|Embedded tag for resource distribution|
    法律状态:
    2020-09-08| B06F| Objections, documents and/or translations needed after an examination request according [chapter 6.6 patent gazette]|
    2020-09-15| B06U| Preliminary requirement: requests with searches performed by other patent offices: procedure suspended [chapter 6.21 patent gazette]|
    2021-01-05| B11B| Dismissal acc. art. 36, par 1 of ipl - no reply within 90 days to fullfil the necessary requirements|
    2021-11-23| B350| Update of information on the portal [chapter 15.35 patent gazette]|
    优先权:
    申请号 | 申请日 | 专利标题
    US36493410P| true| 2010-07-16|2010-07-16|
    US61/364,934|2010-07-16|
    US13/005,872|2011-01-13|
    US13/005,872|US20120016799A1|2010-07-16|2011-01-13|Money transfer system gateway service|
    PCT/US2011/042516|WO2012009165A1|2010-07-16|2011-06-30|Money transfer system gateway service|
    [返回顶部]